Database systems are a common form of computer system that have a wide variety of applications. A database system may be generally defined as a computer system that creates and/or manages a set of related files, or records, which are collectively referred to as the database. Financial records, health records, and other types of records are examples of the type of data that may be created by and stored within database systems.
A database system is usually typified by transactions, such as read and write transactions. In response to receiving a read transaction, the database system reads and returns a particular record or records. In response to receiving a write transaction, the database system may create a new record or records, modify an existing record or records, or, in some types of database systems, delete an existing record or records. In some database systems, write transactions may thus be specifically divided into create transactions, modify transactions, and delete transactions.
In general, maintaining the integrity of the databases in database systems is important, specially for the mission-critical applications. For example, the database system must usually guarantee that transactions are processed in order, such as in the temporal order in which they are generated, or in the temporal order in which the database system receives the transactions. Furthermore, the database system must usually guarantee that transactions are processed, or committed, atomically, such that either the entire transaction is processed, or none of the transaction is processed.
Finally, the database system must typically guarantee that, should some type of failure occur within the system, the database can be recovered so that it reflects the transactions that have previously been committed to the database. One way of achieving this latter guarantee is to write information about the write transactions to a log file. If the database system fails, an older copy of the database can then be updated by the transactions of the log file that are newer than this copy of the database.
However, updating an older copy of the database with the newer transactions stored in a log file can take time. The database system may be down for maintenance while the newer transactions are committed to the older copy of the database. During this time, new write transactions may not be able to be committed to the database, and read transactions may not be able to be processed, such that users are not able to retrieve information stored within the database. For mission-critical and other types of applications, this kind of downtime may be unacceptable.
Therefore, a second instance of a database system may be online at all times. The primary instance of the database system receives transactions, and in addition to committing them to its copy of the database, sends copies of the transactions to the second instance of the database system. The second instance of the database system commits these received transactions to its copy of the database. Therefore, at any given time, two current copies of the database are in existence. Should the first instance of the database system fail, the second instance of the database system can take over as the new primary instance until the first instance recovers.
Database systems achieve such two-instance redundancy usually by shipping, or sending, log records from the first instance of the database system to the second instance of the database system. The log records collectively contain information specifying how to perform and commit the same transactions to the second database, where multiple log records may be needed to describe a single transaction. Failover from the first database instance to the second database instance in case of failure of the former database instance can occur quite rapidly, in near real-time.
Prior art database systems usually send log records from a first instance of a database system to a second instance of the database system in one of two ways. First, and most commonly, the first instance of the database system writes the log records to a log file, which is typically stored on a hard disk drive, then reads these records back from the log file to send them to the second instance of the database system. Transactions within the log records are not actually committed by the first instance until they are at least sent to the second instance, so that the database copies maintained by the first and second instances are in-sync with one another. As such, the first instance of the database system suffers a large performance penalty in sending log records to the second instance of the database system: the latency incurred in having to write the log records to the log file and read them back from the log file before committing their transactions to the database can be substantial.
To overcome this performance penalty, some prior art database systems employ a second approach to send log records from a first instance of a database system to a second instance of the database system. The first instance of the database system, rather than writing the log records to a log file before sending the log records to the second instance of the database system, instead makes, in memory, what are referred to as staging copies of the log records before sending the log records to the second instance and committing their transactions. The staging copies may include whatever additional information the second instance needs to properly ensure that its database is in-sync with the first instance's database.
While the performance penalty the first instance of the database system suffers by using this alternative approach to send log files to the second instance of the database system is reduced by not having to write and read back the log records to the log file before committing transactions, it can still remain significant. The latency incurred in having to make copies of the log records within memory, and the added workload on the first instance's processor, can cause performance degradation. For this and other reasons, therefore, there is a need for the present invention.